<?php
/**
 * <https://y.st./>
 * Copyright © 2019 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Learning Journal',
	'<{subtitle}>' => 'CS 4405: Mobile Applications',
	'<{copyright year}>' => '2019',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<section id="Unit1">
	<h2>Unit 1</h2>
	<p>
		The reading material for the week was as follows:
	</p>
	<ul>
		<p>
			<a href="https://mvellandi.github.io/journal/mobile-application-design-development-app-web-user-interface-interaction/">Mobile Application Design Best Practices &amp;#8211; Keegan Jones and Tim Van Damme</a>
		</p>
		<p>
			<a href="https://my.uopeople.edu/mod/resource/view.php?id=178262">MobileDevGuide.pdf</a>, pages 1 - 59, 75 - 109, and 112 - 121
		</p>
		<p>
			<a href="https://onextrapixel.com/design-best-practices-for-the-mobile-web/">Design Best Practices for the Mobile Web</a>
		</p>
		<p>
			<a href="https://www.ibm.com/developerworks/web/library/wa-interface/index.html"><em>(missing article)</em></a>
		</p>
		<p>
			<a href="https://www.slideshare.net/OpenRoad/mobile-ui-design-user-centered-design-and-ui-best-practices">Mobile UI Design - User Centered Design and UI Best Practices</a>
		</p>
	</ul>
	<p>
		The first thing I noticed as I was looking through the material for the week was that we&apos;re building iPhone mock-ups.
		I really hoped that this wouldn&apos;t be an iPhone-centric course; I&apos;m never in my life going to build an application for a system as locked-down as iOS.
		The iPhone can only install applications that are approved by Apple, and only from Apple&apos;s walled garden of an application store.
		The terms developers agree to when submitting their applications for possible inclusion in the application store require developers to lock down the application and prevent modification of the application.
		Applications under the $a[GNU] $a[GPL], for example, aren&apos;t allowed in the Apple application store.
		I will never write locked-down code like that, so anything iPhone-specific is utterly and completely useless for me.
		Such studies would surely be useful to some students, but certainly not me.
		Thankfully, after checking out the reading list, I saw that we&apos;re also doing Android stuff too (as well as Blackberry and Windows stuff).
		While I will likely never have any applications in Google&apos;s application store, Android allows installation of applications from outside sources, so developing for it is an actual possibility for me.
	</p>
	<p>
		It&apos;s sad how locked-down many mobile devices are.
		These so-called &quot;smartphones&quot; are telephones in name only.
		They&apos;re actually pocket computers.
		Can you imagine if desktop computers were only able to run software approved by the company that sold your computer to you?
		That&apos;s what iPhones are like.
		I don&apos;t know why anyone puts up with that garbage, especially as they have to pay an arm an a leg for the privilege of putting up with that garbage.
	</p>
	<p>
		Part of the reading assignment was an article from $a[IBM].
		That article&apos;s missing now though.
		Frustratingly, the $a[URI] now redirects to a hub page for other articles.
		I hate when websites do that.
		Instead of just telling you the article&apos;s no longer available, they give you some other page and if you don&apos;t notice, you&apos;re confused as to what the person that linked you there was trying to show you.
		In this case, if I hadn&apos;t noticed, I&apos;d&apos;ve been confused as to which article was the one I was intended to read instead of realising that it was none of them.
	</p>
	<p>
		The material from Keegan Jones and Tim Van Damme tells us that mobile devices follow us everywhere and have several types of sensory data that they take in about where we are.
		That&apos;s exactly why you need a device you can trust or no device at all.
		Otherwise, your device can keep tabs on you and send your data back to its real masters: the company that made it.
		There&apos;s a reason I run a fork of a fork of Android that has all the Google sourceless garbage removed.
		(I&apos;m hoping to get a full Debian fork device called the Librem 5 at some point in the future, though it hasn&apos;t been released just yet.)
		No source code means you don&apos;t know what it&apos;s doing, and it&apos;s probably doing something you&apos;d rather it not do.
		The built-in $a[GPSr] can be especially creepy to people that don&apos;t understand that they don&apos;t actually control their device.
		For example, several people I know have ads pop up on their device that are always eerily relevant to where they currently are.
		They feel watched.
		And to be honest, they <strong>*are*</strong> being watched through their device&apos;s $a[GPSr].
	</p>
	<p>
		Another important thing this material covers is button size.
		Many devices are tiny.
		That&apos;s how they fit in our pockets so well.
		But our fingers are too large to use the things super nimbly.
		It&apos;s best to have buttons at least 44 pixels by 44 pixels so we don&apos;t fat finger the buttons and hit the wrong ones as often.
	</p>
	<p>
		Next, it covers tips on what to do when converting a website into a mobile application.
		My recommendation though: <strong>*don&apos;t*</strong> convert a website into a mobile application.
		All these company-specific mobile applications are a waste of device storage, not to mention that they allow more access to a user&apos;s device than the company should have.
		I guess yeah, if you&apos;re one of those creepy companies, that&apos;s exactly what you want.
		But if you&apos;re a reasonable company, just have a website that works well on both mobile devices and larger devices such as desktops and laptops.
		Users don&apos;t have to install extra garbage, nor do they have to update when you add new features.
		Keep website stuff on actual websites.
		The material brings up a valid counterpoint, namely that a native application is faster for users than a website.
		The other points in makes &quot;in favour&quot; of native applications are exactly why users should choose websites instead though, such as $a[GPSr] access.
	</p>
	<p>
		For dealing with multiple screen resolutions, the material recommends making the high-resolution images first, then downscaling.
		That&apos;s probably the best way to support multiple resolutions.
		Doing the reverse causes your high-resolution images to be pixilated.
		Even if you start large and downscale though, you may need to touch up the downscaled images a bit.
		Some designs that work well when you have a lot of space to work with don&apos;t work so well when you&apos;re short on pixels.
		The material also recommends vector graphics.
		I&apos;ve just barely started learning to work with vector graphics myself, but they seem like a great option for graphic images.
		Ways to save space are also discussed, such as making small versions of your buttons and stretching out the very centre pixel when you need larger buttons of the same style.
		A &quot;scratch file&quot; housing all of your assets was briefly mentioned, which might also be for space-saving reasons, though I&apos;m not sure.
	</p>
	<p>
		Also, user feedback is vital.
		You think your application is easy to figure out because you already know completely how to use it, but your clever design might not actually be very intuitive.
	</p>
	<p>
		The best design practices article brings up the fact that mobile website development is becoming more and more mandatory for Web developers.
		Even I have tested out my website on a mobile device to make sure the design was right.
		I had to account for the fact that mobile devices, or at least the one I used test, doesn&apos;t handle $a[CSS] flex boxes.
		I don&apos;t believe mobile versions of websites are a good thing.
		Allowing the user access to different content or content provided in different formats based on what device they&apos;re currently on is frustrating.
		I&apos;ve had times, for example, that a website dumbed-down its interface so I couldn&apos;t do the one thing I&apos;d actually come to the website to do just because the developer wanted mobile users not to have so many options to worry about.
		Mobile and desktop users should be presented with the exact same page and the exact same content.
		However, you should present the content in a way that looks good for both desktops and mobiles.
		And to make things easier, the $a[CSS] specification allows you to define a different style sheet for mobile devices.
		That allows you to adjust the appearance without omitting vital functionality that you don&apos;t realise is vital.
		You don&apos;t know which functionality your users actually need access to on the go.
		As the article says, responsive design is important here.
		Use $a[CSS] to tell the device how to adjust the page to deal with its small screen size instead of serving different content.
	</p>
	<p>
		The article also talks about navigation design.
		It says to use large, button-like links.
		I suppose that&apos;s reasonable.
		It helps users touch the link they actually meant to.
		It says to use a vertical navigation menu too, which I have mixed feelings about.
		Your navigation menu should be on nearly every page, and vertical navigation menus look really odd when they have content below them on the page.
		They&apos;re really better for navigation-only pages.
		It says to keep the number of navigation options minimal too, though that, again, requires dumbing down your mobile site, which can be very frustrating to users.
		Icons are a good idea it brings up though.
		Icons take up space, making the clickable region of the screen a bit larger, and also make it easier to spot what you&apos;re looking for.
		I don&apos;t think using icons is right for every website, but it&apos;s something to consider, and is often a good idea to implement.
	</p>
	<p>
		The article says that horizontal scrolling should be avoided on mobile websites.
		Let&apos;s face it though: horizontal scrolling should be avoided on websites.
		Full stop.
		This isn&apos;t a mobile-specific issue.
		It may be more of a pain on mobile devices, but it&apos;s a pain on desktops and laptops too.
		Even without horizontal scrolling, the article recommends making pages smaller, for example, by splitting up large pages into multiple smaller pages.
		That&apos;s probably good advice as long as you don&apos;t go overboard with it.
		If pages are too small, users have to go through page after page to find what they&apos;re looking for.
		There are websites that present, for example, top ten lists in which each page houses one of the ten things, and there&apos;s only a short paragraph or two on each page.
		This is what it looks like to go way too far in splitting up your pages into smaller ones.
		The article also recommends accordion-style collapsing of sections you&apos;re not reading.
		Those probably work much nicer, especially if your $a[CSS] is set to expose the full content right away to larger devices such as desktops.
		That way, the mobile user still sees the full content, but doesn&apos;t have to deal with it all at once.
	</p>
	<p>
		A great point is also made that we shouldn&apos;t cramp everything together.
		Trying to squeeze every bit of content we can onto the screen hinders usability.
		White space is a requirement; it&apos;s not the enemy, when used well.
	</p>
	<p>
		I tried to read the content of the slide show, but the slide show wasn&apos;t responding.
	</p>
	<p>
		The textbook brought up the concept of &quot;hybrid&quot; mobile applications: part native code and part data fetched from the Web.
		These have the disadvantage of native applications in that they&apos;re not safe to install if public source code isn&apos;t available, and seem almost like restrictive Web browsers (they fetch Web data, but you can&apos;t go to arbitrary websites).
		I&apos;m really not sure why I&apos;d ever build one myself, though I can easily see why some big companies do it.
		It offers them options, such as applications with up-to-date information without the user having to update the application.
		Again though, plain websites seem like a better and safer option for the user.
	</p>
	<p>
		The idea of prototypes for applications seems pretty useful.
		In particular, the textbook mentioned that a prototype can tame any of many forms.
		The idea it presented of an $a[XHTML] (ostensibly with $a[CSS]) prototype with clickable links in place of buttons seemed like something I&apos;d be able to put together well.
	</p>
	<p>
		As the textbook says, Android is developed by the Open Handset Alliance, which is led by Google.
		It&apos;s ironic that the group is called that though.
		Android has a lot of components, but they can be broken into two groups: parts belonging to the Android Open Source Project, which are open, and components belonging to Google Applications, which are proprietary and locked down.
		In order to be allowed membership in the Open Handset Alliance, inclusion of the locked-down Google Applications is mandatory.
		In other words, membership in the alliance requires that the handsets you sell not actually be open.
	</p>
	<p>
		It seems there&apos;s Android-specific terminology used to refer to some things.
		This terminology would be good to remember when reading $a[API] documentation and the like.
		For example, a process with a user interface is called an &quot;activity&quot;.
		Background processes are called &quot;services&quot;.
		Broadcasts between applications or from the system to an application are called &quot;messages&quot;, and are handled by &quot;message receivers&quot;.
		Triggers tto the system sent by applications are instead called &quot;intents&quot;.
		A &quot;data provider&quot; abstracts away the details about persistent storage.
	</p>
	<p>
		I have some experience with $a[ADB], though not much.
		I&apos;ve never managed to get an Android emulator working though.
		Hopefully that&apos;ll change this term.
		I&apos;ve also had trouble getting a working Android development environment set up, so maybe the material this term will help me learn how to get that working correctly as well.
	</p>
	<p>
		The textbook says that once developed, Android applications should be submitted to Google Play.
		That <strong>*really*</strong> needs to be thought about before you just jump right into it though.
		You have to agree to Google&apos;s terms of service and buy into Google&apos;s noxious practices to get a Google account, and you can&apos;t submit applications to the Play Store without one.
		If you&apos;re a big, faceless corporation, then sure.
		Hands down, you want your application where it&apos;ll get the most downloads, regardless of what you have to buy into.
		So go with the Play Store.
		If you value your security and privacy though, having a Google account is a really bad idea.
	</p>
	<p>
		The textbook said that all Blackberry devices are made by the same company.
		It pointed out that this has reduced fragmentation of the platform.
		It also means less competition though; it&apos;s a monopoly over the platform.
		It seems Blackberry is pretty locked down as well, requiring a signing key from the developers (which means, you need the permission an approval of the company) for even certain basic features such as access to the filesystem and network connectivity.
		It seems the platform isn&apos;t technically as locked down as iOS, but it&apos;s pretty locked down an you can&apos;t do much of interest without the approval of the company.
	</p>
	<p>
		It&apos;s interesting that Blackberry 10 provides so many $a[API]s to build applications against.
		In particular, the option to use the Android 2.3.3 $a[API] on Blackberry 10 could make it easier for Android developers to provide a Blackberry version of their applications.
		At first I thought that alternatively, Blackberry 10 users might be able to just run Android applications in some cases, though if Blackberry 10 has the same requirement that a signing key be gotten from the company to do anything interesting, applications meant for Android aren&apos;t going to function on Blackberry 10 because they&apos;ll be signed with a key not given by Research In Motion, the makers of Blackberry.
		It turns out it&apos;s a moot point though.
		Android packages aren&apos;t compatible with BlackBerry 10, which despite running code developed using the Android $a[API], only runs applications packaged in BlackBerry 10&apos;s own package format.
		Of note though, it&apos;s possible to request a debug token, which unlocks a Blackberry 10 device enough to get it to run unsigned code.
		You can&apos;t expect most people to have one of these debug tokens, and I&apos;m not sure if Research In Motion always grants requests for them, but if you get one, you can run whatever code you like to.
		It&apos;s easier just to choose a better, less locked-down system such as Android though.
	</p>
	<p>
		The section on iOS says that iOS is capable of running third-party applications.
		While technically true, what it doesn&apos;t make clear right away is that it can only run third-party applications that have been approved by Apple.
		You can&apos;t just install whatever third-party applications you want to, and if you&apos;re a developer, you can&apos;t just develop applications for iOS without Apple&apos;s permission and approval.
	</p>
	<p>
		The section on Windows says applications can only be distributed through Microsoft&apos;s application store, and thus permission from Microsoft is required for making your applications runnable, and Microsoft takes their cut of the revenue, but the textbook also says applications meant for the desktop will run on the mobile, and no such requirement is placed on Windows desktop applications.
		Maybe the mobiles simply wont&apos; run files gotten from elsewhere?
		Anyway, the obvious takeaway for me is that, again, this platform is too locked-down for me to develop for.
		The part about using a Microsoft Account to manage authentication for non-Microsoft applications caught my attention though.
		This seems like a terrible idea from a privacy and security standpoint, but is probably very convenient for users that don&apos;t care about such things.
	</p>
	<p>
		The idea of cross-platform development sounds promising in some ways.
		As I mentioned, I have no intention of developing for most of these platforms.
		Android and probably Firefox OS (which was mentioned, though not covered in the part of the textbook we read this week) both seem like platforms I might one day want to release applications for, and it&apos;d be nice not to have to develop them twice.
		Full Linux desktops are coming to mobile pretty soon too, so developing for all three would be nice.
		It sounds like the most-challenging part of cross-platform development though is making the applications look and feel like they belong to each platform.
		Development time needs to be spent on each platform to make sure each set of design philosophies is handled properly.
		Much of it seems like users just being unable to adjust to small differences in the interfaces between different applications and needing a uniform experience across applications.
		Part of it makes perfect sense though, such as that different platforms have different hardware buttons that should actually function in your application.
	</p>
	<p>
		The section on mobile Web development mentioned that developing a website is easier than building an application, which is useful.
		More importantly though, it mentions how it frees you from the need to get the approval of application stores.
		This is huge.
		These big companies shouldn&apos;t be the gatekeepers that determine what users can install, but they are.
		They don&apos;t act as gatekeepers to the Web though.
		The Web is still fully accessible to users.
		Client-side versus server-side adaptation was covered.
		Server-side adaptation seems to nearly always be the wrong solution.
		At the very least, <code>User-Agent</code> sniffing is a noxious practice that often leads to incompatibilities for lesser-known browsers even when said browsers would be fully able to render the regular, non-adapted code of a regular implementation of the page.
		If you look only at the browser&apos;s reported capabilities, not its <code>User-Agent</code> string, you can get a less-terrible server-side adaptation set up, but client-side is probably still the way to go in nearly every case.
		The textbook states inability to serve different content to different devices as a negative, but as far as I&apos;m concerned, sending the same content to all devices should be the goal.
		As a user of websites, I find the dumbed-down mobile sites to be next to useless.
		I can&apos;t be the only one, either.
	</p>
	<p>
		So-called &quot;progressive enhancement&quot; is a terrible idea.
		The concept is that you start with a bare-bones page, then progressively add to the page using JavaScript.
		Do you see the obvious problem?
		That&apos;s right: over-dependence on JavaScript.
		Users without JavaScript enabled or with browsers that aren&apos;t JavaScript-compatible get the bare bones page, possibly without any actual content, depending on how you set up your page.
		These types of pages are annoying, not to mention that some users, such as disabled users using assistive technologies, may not be able to reach your content.
		JavaScript should provide added functionality to provide a better experience.
		It should <strong>*not*</strong>, however, be worked in as a vital part of making your page even usable.
	</p>
	<p>
		This seems to be the easier of my two courses this term.
		While I didn&apos;t agree with some of the material, I&apos;m pretty sure I understood it all.
		In my other course, I haven&apos;t been so fortunate.
		Much of the material seems to be above my head.
		It&apos;s going to be a struggle to get through that course.
		As I&apos;m sure you can tell by my opinions on things, I&apos;m never going to be a mobile application developer.
		I may and probably even will develop at least one mobile application for my own use, and will share the application (and source code) if I do, but I don&apos;t have what it takes to develop applications, mobile or otherwise, for a faceless corporation that would lock down the code to prevent others from using it.
		Or even a fresh start-up that wanted to lock down their code.
		I just wouldn&apos;t be able to be happy if writing locked-down, proprietary code is what I chose to do with my life.
	</p>
</section>
<section id="Unit2">
	<h2>Unit 2</h2>
	<p>
		This week&apos;s reading assignment was chapter one of <a href="https://my.uopeople.edu/mod/resource/view.php?id=178261">The Busy Coder&apos;s Guide to Android Development</a>.
		When I read about Android development, I always worry that what I&apos;m reading may be too recent.
		As I discussed last week, I have no use for vanilla Android, and use a fork of a fork of it, with the Google garbage removed.
		The project&apos;s short-staffed though, as it&apos;s not exactly popular, so the version of Android they work with is pretty old.
		If the material is too recent, it won&apos;t all work on my distribution.
		This book, however, was written for Android 3.0.
		Wow.
		That&apos;s even older than what my distro works with.
		And my understanding is that anything written for an older version of Android is supposed to run on newer versions of Android as well.
		So aside from any Google-Applications-specific $a[API]s discussed, everything I learn from this book should be usable on my distribution.
	</p>
	<p>
		The first student I graded work for didn&apos;t explain their application design at all, and included both a picker and a keyboard on all three of their mobile screens.
		It crowded out the other items of the interface.
		I really don&apos;t think they knew what they were doing.
		I mean, I didn&apos;t know what I was doing either, and I still produced a clean-looking interface that at least seems sensible.
		It probably has usability issues I haven&apos;t thought of, but you can tell what&apos;s going on in the screenshots.
		And if you can&apos;t, at least there&apos;s written descriptions explaining everything.
		The next student&apos;s work showed a much cleaner interface, and despite the lack of a description, their intent was mostly clear.
		Their application tracks the cost and/or distance of vehicular journeys.
		The third student uploaded a screenshot of the instructions of how to take a screenshot on Windows instead of one of the three screenshots of their application, so only two of their prototype screenshots ended up submitted.
		Their interface was likewise pretty clean and mostly intuitive.
		It seemed to combine garden plant photography and fuel efficiency calculation into the same application, which was a bizarre design decision, but the interface was still pretty clean.
		Unfortunately, I had no choice but to grade the messy, poorly-designed application with the highest grade.
		The other two submissions left out multiple interface objects that both the assignment instructions and the rubric demanded.
		The student that didn&apos;t seem to know what they were doing had left only one thing out that they&apos;d been asked to include.
		That&apos;s the problem with rubrics: it&apos;s difficult to create one that adequately captures everything that should be taken into account.
		The students with better designs are to blame for their own loss of points; they were told very clearly to include certain elements.
		For me, that meant putting in elements that compromised my design and would have better to have replaced with other interface elements, but I followed the instructions.
		These students hadn&apos;t.
		But for the student with seemingly no concept of what they were building, it still seems incorrect for them to have the highest grade.
	</p>
	<p>
		On the assignment this week, we were supposed to complete part of a course on another website.
		After the first video, an introduction to the course, the site asked me a series of questions.
		I thought I should answer them truthfully, and that they were trying to get a feel for where I was in terms of what I already knew.
		Apparently not.
		Instead, they wanted me to lie through my teeth.
		The first question asked how much experience I had with Java.
		I chose the less than a year option, and the site marked me wrong and told me to try again.
		Seriously?
		To move on, I have to lie and say I&apos;ve had more experience with the language than I have?
		That&apos;s just ridiculous.
		This questionnaire was ridiculous.
	</p>
	<p>
		The external course explained the version-naming pattern: the names are alphabetical.
		It&apos;s pretty annoying to have version names at all though.
		Version numbers allow easy comparison between versions of a project.
		If the developer is at all sane and at all reasonable, and you&apos;re looking at version 5.4 and version 7.2, you know that version 7.2 is newer.
		You just compare the numbers separated by full stops from left to right until you find one that doesn&apos;t match, then assume the one with the bigger number is newer.
		But you don&apos;t have that luxury with version names.
		Over the past decade, there seem to have been several projects that assign their names alphabetically, increasing the first letter at each major version update.
		Android seems to be one of those projects.
		But not all projects do that.
		You can&apos;t assume names can be compared like that.
		A great example is from when I used to be an OS X user.
		Various websites would offer software and say you need, for example, Snow Leopard or newer.
		What does that even mean?
		I was on 10.4.11, also known as (if I recall correctly) Tiger.
		Is Snow Leopard newer or older than Tiger?
		The names weren&apos;t alphabetical, and you had to either memorise the sequence of version names or look up the names each time you needed to compare.
		Both were a waste of time.
		If people just used the intuitive version numbers, which OS X does have, comparison would be nearly instantaneous, and take no real effort whatsoever.
		Version names are a disservice to your user base.
		Use version numbers and <strong>*only*</strong> version numbers.
		I don&apos;t care if you think your version names are cute, or cool, or whatever.
		They&apos;re not cute/cool/whatever enough to be worth the hours in total they waste from people&apos;s lives when they have to figure out how to compare your versions or one another.
		Even alphabetically-assigned version names are problematic, as people using your software don&apos;t automatically and don&apos;t necessarily know they you&apos;re using alphabetically-assigned version names.
		Besides, what happens when you get past &quot;Z&quot;?
		Do you wrap back to &quot;A&quot;?
		If so, you version names are no longer in alphabetical order, and people have to go back to figuring out which versions lie on which side of your dividing Z/A line.
	</p>
	<p>
		For that matter, I&apos;m morbidly curious as to what Google will name their &quot;X&quot; and &quot;Z&quot; versions, seeing as they&apos;ve further limited themselves to naming their versions after, as they put it, &quot;sugary treats&quot;.
	</p>
	<p>
		The section that showed how to set up a virtual device gave me some relief.
		It said you could use a version of Android, or use that same version with Google $a[API]s.
		What that means is that using it without explicitly using it with the Google $a[API]s is to use it without those $a[API]s.
		There&apos;s a chance I&apos;ll be required to build an application that targets the Google $a[API]s for a class, such as this one.
		Aside from in a class though, there&apos;s no way I&apos;ll ever build an application against proprietary $a[API]s.
		By doing so, I&apos;d be requiring my users to have said proprietary $a[API]s installed on their device.
		In other words, I&apos;d be doing my users a disservice, not to mention that I&apos;d be endorsing the use of proprietary $a[API]s.
		With proprietary code, you don&apos;t know what it&apos;s doing and you&apos;re not allowed to change it if you did.
		You don&apos;t have control of your device, the software vendor does.
		Fully justified fear and suspicion of the unknown aside, Google&apos;s software that is bundled into most versions of Android are outright known to be dangerous.
		They&apos;re known to keep tabs on your location, for starters, which is creepy.
		But also, they&apos;re known to be able to install and remove software from your system without your consent, and known to be able to wipe your device&apos;s user storage remotely.
		I can&apos;t in good conscience do anything that might encourage users to have the Google garbage installed on their mobiles.
		By having a virtual device without those $a[API]s, I&apos;ll be able to see in the testing environment that my applications behave properly without them.
	</p>
	<p>
		The textbook started off this week by discussing smartphones being telephones, so I&apos;ve got to bring up what I did last week: smartphones are telephones in name only.
		They&apos;re actually pocket computers, which is why they&apos;re so versatile.
		Telephones can&apos;t do most of what smartphones are used to do every day.
		With that out of the way, it then continued about various issues such as form factor of tiny devices, which is valid, but then brought up that one challenge of developing mobile applications instead of desktop applications is that when applications mess up someone&apos;s mobile (various examples were provided, such as resource-hogging and such), people get angry about it.
		Why are they not like that with their other computers?
		For me, I get frustrated when my software starts making my laptop act up as well.
		And if I had a working desktop machine, I&apos;d be mad if software messed that up too.
		Either the majority of people are feel very detached from their non-mobile computers, or the book&apos;s point here is completely invalid.
		Most of the material from the textbook was either a repeat of what I discussed from the assignment for the week, along with a full page listing things that Android can do specifically because it&apos;s not on a telephone, such as access files and the Internet, so I won&apos;t go over those ideas here a second time.
	</p>
</section>
<section id="Unit3">
	<h2>Unit 3</h2>
	<p>
		The reading material for the week was as follows:
	</p>
	<ul>
		<li>
			<a href="https://developer.mozilla.org/en-US/docs/Web/Guide/Mobile">Mobile Web Development - Developer guides | MDN</a>
		</li>
		<li>
			<a href="https://webplatform.github.io/docs/concepts/mobile_web/">Mobile Web · WebPlatform Docs</a>
		</li>
		<li>
			<a href="https://www.html5rocks.com/en/mobile/responsivedesign/">Creating a Mobile-First Responsive Web Design - HTML5 Rocks</a>
		</li>
		<li>
			<a href="https://www.w3schools.com/jquery/">jQuery Tutorial</a>
		</li>
	</ul>
	<p>
		The first thing the Mozilla article sugested was responsive design.
		I fully agree that that&apos;s how multi-device should be implemented.
		It&apos;s for more than just mobiles.
		Some websites haven&apos;t rendered well on past laptops I&apos;ve had even, due to the developers being too incompetent to build anything besides an idiotic fixed-width page.
		For me, there was a screen size issue, just like with mobiles, but to a lesser extent.
		However, this isn&apos;t even strictly a screen size problem.
		Not every user wants a full-screen browser window.
		Even on a large screen, smaller browser windows are often much more convenient for the user.
		Before I switched to Linux, I used to never use full screen windows when I didn&apos;t have to.
		They made me feel cramped in, as I couldn&apos;t see multiple things that I was working with.
		On Linux, things have been a bit different for me, as I now have access to as many desktops as I want, which I can switch to with a single click.
		I keep my system configured to have four desktops, and each one has its own set of windows, so I can easily and quickly switch between sets of tasks.
		With this setup, I almost always use full-sized windows except when I&apos;m getting a screenshot for school, in which case I shrink the window down as much as feasible for smaller image dimensions.
		But without this multi-desktop feature, I wouldn&apos;t be using full-size windows when I don&apos;t have to, and I&apos;d continue to be very annoyed with fixed-width webpages that force me to bump up my windows size just to render usably, especially in times when even full-sized windows aren&apos;t enough on my modest screen.
	</p>
	<p>
		The next tip the article gave was to use the <code>viewport</code> <code>&lt;meta/&gt;</code> tag.
		I actually learned about that tag the hard way.
		The thing is that many mobile Web browsers are pretty foolish in their default rendering of a webpage.
		They&apos;ll smash all the text into a column that if zoomed in to, would look perfect.
		But then they render the page zoomed way out.
		You end up with a mostly-blank page with all the text smashed to the left side, which is very ugly, not to mention inconvenient.
		Using a <code>viewport</code> <code>&lt;meta/&gt;</code> tag, you can tell mobile Web browsers to render your page in the intuitive way that they already should by default so your page doesn&apos;t look like utter garbage.
		It&apos;s completely a Web browser flaw, not a webpage flaw, but it&apos;s incredibly easy to fix the rendering of your page by adding this tag to your webpage.
		Its very easy to see that it&apos;s the browser to blame though when you try looking at a bare-bones page that only uses <code>&lt;p/&gt;</code> tags within the <code>&lt;body/&gt;</code> tag and the browser still manages to botch the rendering.
	</p>
	<p>
		The dangers of expecting users to hover over elements was mentioned, but is self-explanatory, so I won&apos;t go into detail.
		It&apos;s a good thing to keep in mind though.
	</p>
	<p>
		Mozilla also recommends using <code>-moz-touch-enabled</code> as a media type for $a[CSS] to be loaded on a mobile device.
		<strong>*DO NOT DO THIS!!*</strong>
		I cannot emphasise that enough.
		This is <strong>*not*</strong> a standards-compliant value.
		This is browser-specific garbage that doesn&apos;t belong on any website.
		Just look at that &quot;-moz&quot; part.
		Do you think that value&apos;s understood by non-Mozilla mobile browsers?
		No.
		Not a chance.
		This sort of idiocy is the type of thing that leads to <strong>*less*</strong> support for Web browsers, because developers are wasting all their time on these browser-specific <strong>*hacks*</strong> instead of standards-compliant code that runs on all working Web browsers.
		Developers don&apos;t have the time and energy to provide browser-specific hacks for each and every Web browser, so they end up supporting only a few popular ones, and leaving the rest with nothing, even when those other Web browsers would render a standards-compliant webpage perfectly.
		Don&apos;t use this sort of hack.
		Ever.
		Instead, use actually-valid code, such as the <code>max-width</code> feature of a <code>@media</code> query.
		Bizarrely, a bit down the page after telling readers to use this browser-specific hack, Mozilla then recommends against browser-specific hacks, and even specifically says to avoid things with browser-specific prefixes (y&apos;know, such as that &quot;-moz&quot; prefix that they <strong>*just*</strong> recommended using).
	</p>
	<p>
		The final noteworthy piece of advice the article provides is to be careful when using <code>User-Agent</code> strings to determine what to send users.
		They say that if you use the <code>User-Agent</code> string at all, you need to make sure your algorithm is correct in its assessment of what users are using.
		That&apos;s a complete joke though; your algorithm can <strong>*never*</strong> be correct 100% of the time.
		You can&apos;t account for every <code>User-Agent</code> string out there.
		You&apos;re going to get some wrong.
		And that&apos;s ignoring the fact that some users set this string to something that doesn&apos;t match their actual browser, so your guess will sometimes be wrong even if you recognise the <code>User-Agent</code> string.
		They might do this for privacy reasons, or they might do it because some stupid website like yours won&apos;t send proper code except to certain browsers, so they have to, but then your website sends different code that wont&apos; render correctly based on that same <code>User-Agent</code>, so the user had no way to win.
		Seriously.
		Never use the <code>User-Agent</code> string for anything.
		There are no excuses for this.
		The fact of the matter is that the <code>User-Agent</code> is a blight on the Web.
		It&apos;s a remnant from the browser wars, and was used specifically to try to get people to switch to whatever browser you&apos;d prefer they use.
		At times, it was used to actually provide support for multiple browsers as well, as each Web browser vendor was using their own non-standard version of $a[HTML].
		The importance of standards is starting to be pretty widely accepted at this point though.
		Honestly, the Web would be a much better place if the <code>User-Agent</code> string was dropped from $a[HTTP] altogether.
		Never rely on this string.
	</p>
	<p>
		The $a[HTML]5 Rocks page brings up a good point in saying that we should use semantic markup on our pages.
		While this is brought up in the context of mobile devices, semantic markup is about so much more than mobiles.
		Assistive technologies such as screen readers for the blind also depend heavily on pages being marked up correctly.
		Semantic markup also makes it more clear to future developers that work on your site, if you&apos;re developing for a company or something, what your intention was so they don&apos;t accidentally break it.
	</p>
	<p>
		The $a[HTML]5 Rocks page also makes the claim that mobile devices try to display non-mobile-optimised sites with a large viewport because such sites will render better that way.
		As I showed in my example a bit ago though, this is patently false.
		Yes, a huge viewport is selected by default.
		However, the text on the page is squished into a column much narrower than the page, behaving as if a much smaller viewport were being used.
		Clearly, this isn&apos;t how a non-mobile-optimised site would want to be rendered either.
		No one wins from this behaviour; not sites intending to be seen on a mobile and not sites that completely ignore the presence of mobiles.
		This default behaviour is completely ridiculous.
	</p>
	<p>
		The site also recommends the use of $a[HTML] special characters instead of images when feasible, then gives some examples such as Unicode stars in place of a star image for ratings.
		That&apos;s a pretty good idea.
		If you&apos;re using $a[XHTML]5 instead of $a[HTML]5, you can make the page size even smaller by including the Unicode characters directly in the code.
		It might work with $a[HTML] as well - I&apos;m not sure, as I avoid using $a[HTML] like the plague - but it definitely works in $a[XHTML], and is even the recommended way of using special characters.
	</p>
	<p>
		The page also briefly mentions that using the <code>em</code> unit is better than using the <code>px</code> unit, justifying this by saying that <code>em</code> responds to user font settings.
		Another good reason for this is that <code>px</code> refers to pixels, and you don&apos;t know how <strong>*densely packed*</strong> the pixels on a user&apos;s screen are.
		A pixel-based measurement on a low-resolution screen may make things render well for one user, while making things completely unreadable for another user on a high-resolution screen.
		Likewise, a measurement taken on a high-resolution screen might make the page way too huge to display well on a low-resolution screen.
		I think I read that some devices use this measurement to refer to actual pixels, while others use it to refer to a unit of measurement that is about the size of what a common pixel size is (to avoid screen-resolution-specific rendering), regardless of the actual pixels on the device.
		<code>px</code> really doesn&apos;t give you a good tool to work with when trying to get anything done.
		<code>em</code> is more flexible in almost every way.
	</p>
	<p>
		As for the Internet Explorer conditional tags the page recommends, those are more browser-specific hackery, and should therefore be avoided.
		The same goes for the vendor prefixes the page mentions a bit later.
		As the Mozilla article said, avoid the use of vendor prefixes.
	</p>
	<p>
		When grading this week, the first student I graded only completed 73% of the Creating Project Sunshine lesson.
		The percentage is provided right there on the page they screenshotted, so I&apos;m not sure how you could mess that up.
		The instructions clearly said to go through the whole lesson.
		It should have been an easy week, where everyone got full marks.
		Seriously.
		The third student I graded didn&apos;t even submit a screenshot, and instead submitted only a single full stop character.
		Um.
		What?
		I really don&apos;t get why they submitted anything if they hadn&apos;t taken the screenshot, but if they were going to submit without the required screenshot, it seems like they&apos;d at least write up some affirmation that they&apos;d done the work or something.
		But no, just a full stop.
	</p>
</section>
<section id="Unit4">
	<h2>Unit 4</h2>
	<p>
		As feedback for my <a href="https://y.st./en/coursework/CS4405/#Unit2">Unit 2 learning journal</a> submission, you said that I&apos;d mentioned my machine locking up on me.
		I reread my entry, and I can&apos;t find where in there I even said that.
		Do you have me mixed up with another student?
		My machine has indeed been locking up in my <strong>*other*</strong> course, where we&apos;re using <code>three.js</code>, which is a huge resource hog, but nothing we&apos;ve done in this course has done anything of the sort.
		But also, you recommended checking to see if my machine meets the minimum system requirements.
		I looked up the <a href="https://www.uopeople.edu/programs/ed/degrees/master-of-education-med/technology-requirements/">university&apos;s system requirements page</a>, and found that this school doesn&apos;t have any.
		None, aside from wanting the latest version of one of several browsers installed.
		The page says that even a mobile device will suffice, and my laptop runs a lot faster than my mobile ever did.
		But also, this is the only machine that can get on the local Wi-Fi network.
		It&apos;s $a[MAC]-address-whitelisted, so if I replace my machine, I&apos;m blocked from the Internet.
		Which is too bad for me, because I have a brand new laptop that I can&apos;t use for school because it can&apos;t get online when I&apos;m at home, and have to use my really old one for everything that I do, for now.
		And before you ask, it&apos;s not my router, so it&apos;s not my whitelist.
		I can&apos;t modify it.
	</p>
	<p>
		This week&apos;s reading material was as follows:
	</p>
	<ul>
		<li>
			<a href="https://docs.oracle.com/javase/tutorial/java/index.html">Trail: Learning the Java Language (The Java™ Tutorials)</a>
		</li>
		<li>
			<a href="https://tutorialspoint.com/java/java_overview.htm">Java Overview</a>
		</li>
	</ul>
	<p>
		This week, it seems we&apos;re focussing on learning Java.
		I&apos;ve already worked with Java in a few other courses here at this school though.
		I certainly need more practice, but I&apos;ve got the basic things covered by the reading assignment down already.
		I did see a few interesting things in the reading material though.
	</p>
	<p>
		The overview said that Java code is platform-independent and not compiled for a particular machine.
		It&apos;s certainly platform-independent, but it&apos;s compiled for a very specific machine every time: the Java Virtual Machine!
		This machine doesn&apos;t exist.
		No hardware has ever been built that actually implements the way this machine is defined to work, as far as I know.
		But it&apos;s still compilation for a specific machine none the less.
		The Java Runtime is basically just an emulator that runs Java bytecode on machines and systems not designed to run it.
		Of course, as an emulator, it implements $a[API]s not necessarily available on the host system using the host system&apos;s own $a[API]s, which is where the cross-platform compatibility comes in.
		An emulator built for each of two systems will perform the same actions on those two systems, and the emulated system&apos;s $a[API] calls are simply implemented in the $a[API] calls of the host systems.
		It was also claimed that Java is interpreted, which again, isn&apos;t true.
		It&apos;s a compiled language.
		If you emulate a system, you can&apos;t claim that compiled code that runs on your emulated system is an interpreted language.
		It&apos;s still a compiled language.
	</p>
	<p>
		As a side note, it actually took me quite a while before I understood where Java fits when it comes to being a compiled or interpreted language.
		It gets compiled into byte code, which I was told wasn&apos;t an executable, and needs to be run on the Java runtime, like you&apos;d run a script in the interpreter of an interpreted language.
		How Java bytecode actually works isn&apos;t discussed all that often; it just gets said that you compile it, but you still need to run it on the runtime.
	</p>
	<p>
		It was claimed that Java is designed to be easy to learn.
		If that were true, the feature known in Java as method overloading wouldn&apos;t be present.
		This feature allows you to give multiple methods identical names so long as the signatures differ (that is, the combination of the method name, the number of parameters the method takes, and the types of those parameters) so the compiler can properly distinguish which method should be called when you call a method.
		This seems fine until you look at the mess it causes.
		If you make a mistake when you pass arguments to a method, the compiler will complain that you tried to call an undefined method, not that you passed in values with the wrong types.
		This means that if you&apos;re new to the language, you try to find typos in your method names (both where you declared the method and where you called it) and when you can&apos;t find any, spend hours trying trying to debug why a method that is clearly defined before being called somehow isn&apos;t defined at the point you called it.
		There&apos;s no valid reason for this.
		If you have multiple methods that do similar things, but take different argument types, just give them slightly-different names.
		An excellent example of this is OpenGL.
		In my other course, I&apos;m learning about the OpenGL $a[API], which has several functions that do essensially the same thing, but taking different argument types.
		One takes a float and another takes an integer, for example.
		To distinguish, the argument types are referenced in the names of the functions, which are otherwise named identically.
		That&apos;s all it takes.
		There&apos;s no need to <strong>*ever*</strong> name multiple methods the same thing, with the exception of (arguably) the constructor methods.
		Separate names makes the $a[API] more clear and prevents such misleading compile error messages.
	</p>
	<p>
		For that matter, if Java is designed to be easy to learn, why does it use bizarre terminology that doesn&apos;t match what other languages use?
		As a quick example, in just about every language, an argument is a value passed to a function or method, while a parameter is a placeholder variable used in the function/method signature and within the body of the function/method that takes on a value supplied as an argument.
		In Java though, parameters and arguments are <strong>*both*</strong> called &quot;parameters&quot;, and you have to use a qualifier to get across what you mean.
		A &quot;formal parameter&quot; is a parameter and an &quot;actual parameter&quot; is an argument.
		If Java was intended to be easy to learn, its designer utterly failed in that mission in several key ways.
	</p>
	<p>
		The overview likewise claimed that in Java, you can develop virus-free systems.
		I <strong>*highly*</strong> doubt that.
		Nothing that can run arbitrary code (as nearly every useful system can) can be completely impervious to viruses.
		The simple fact is that to a computer, there&apos;s no such thing as viruses.
		There is only data and data that can be executed as software.
		A virus does something that the user doesn&apos;t want, but it usually does it through the system&apos;s intended $a[API].
		Sure, there are vulnerabilities that could be exploited, but software doesn&apos;t need to exploit a vulnerability to be considered a virus, nor does exploiting a vulnerability mean the offending code is a virus.
		There&apos;s no distinguishing factor in the code itself that determines the code to be a virus.
		You can&apos;t set a system - the Java Virtual Machine included - to run non-viruses while not running viruses.
		Reality doesn&apos;t work that way.
	</p>
	<p>
		The section on Java&apos;s free software status was interesting.
		I was aware that there was a free software version of Java, known as OpenJDK, and a proprietary version, just called Java (I think? I don&apos;t pay much attention to the proprietary version.), but I wasn&apos;t really sure what the difference was.
		OpenJDK is developed by Oracle, who also develops the proprietary version, and I wasn&apos;t sure what the point was.
		OpenJDK is supposedly not gimped like some free software versions written by companies that want to get you hooked enough to buy into their proprietary version, so why have the proprietary version?
		It seems this stems from when Sun held the copyrights to most of Java though.
		They made most of it free software, but didn&apos;t hold the copyrights to part of it and couldn&apos;t freely license it.
		I think those parts have been replaced with free software components now though.
	</p>
	<p>
		This was a slow week in this course, my other course is going nowhere so I&apos;ve quit giving it the level of attention I&apos;d previously been giving it, and I had an extra day off from work this week, so I got to work and finished the third-party lessons we were told would be due in Unit 6.
		When I tried to log into the site, it hit me with a birth date entry wall, claiming that the authorities in my region require me to enter my date of birth to comply with privacy laws.
		Having to enter personal information is the exact opposite of privacy though.
		This isn&apos;t a privacy law, that&apos;s for sure.
		If any law requires this, it is by definition not a privacy law, even if your country tries to lie and claim it is.
		I tried resetting my connection once to access the site from another country, but the site still claimed authorities in my region were requiring this.
		Because of that, I&apos;m pretty sure it was a lie, and they were just being nosey.
		I should have reset my $a[IP] address a few more times and tried a few more countries to be sure, but I just wasn&apos;t feeling it that day.
		So I told them I was born on the date of the Unix Epoch: 1970-01-01.
		It&apos;s a date any tech-minded person should know, and it definitely doesn&apos;t tie back to me personally, so I can keep my privacy.
		It&apos;s really none of their business.
		They can have my name, if they want it, and they already have my email address.
		But that&apos;s the extent of the personal information I&apos;ll give them.
	</p>
	<p>
		After completing the video lessons, my general impression of mobile development is that Android seems to be an interesting platform to develop on, but it&apos;s also full of easy pitfalls and subtle gotchas.
		And with all the problems, I&apos;ve got to wonder if the platform&apos;s worth my time.
		I mean, learning how the platform works is great, and definitely worth my time, but is actually developing applications on it worth my time?
		Another thing to keep in mind is that Google refuses to allow me to register an account.
		That means I can&apos;t submit any application I release to Google Play.
		Obviously, I would want to submit my application to better distribution systems, such as F-Droid, but submitting to F-Droid doesn&apos;t mean not also submitting to Google Play.
		The two aren&apos;t mutually exclusive.
		And without submitting to Google Play, the number of people that&apos;d even find my application, whether they decide to install it or not, will be severely limited.
		Developing for the desktop not only seems easier, but also seems more likely to build a user base.
	</p>
	<p>
		It seems that Android skips zero when indexing menu items, so when you choose your menu item order, you start at one.
		I&apos;m almost certainly going to forget that in the future.
		I wonder how difficult that&apos;ll be to debug.
	</p>
	<p>
		The course says that $a[URL]s are a type of $a[URI], but doesn&apos;t explain what that means, so I figured I&apos;d talk about that here.
		The $a[IETF] used to provide two separate terms for strings in this format.
		There were $a[URL]s, which provide information on where a resource can be found but not what that resource is, and there were $a[URN]s, which specify a name for a resource, but give no indication as to where that resource can actually be acquired from.
		Later, the $a[IETF] realised that these strings were very much the same in many regards, and deprecated both terms.
		Now, the unified term, $a[URI], is preferred.
		$a[URI]s and $a[URL]s still exist, but they&apos;re all called $a[URI]s.
		Use of the deprecated terms, $a[URL] and $a[URN] are discouraged, but may legacy $a[API]s such as Java&apos;s still reference the older terms, and many people simply don&apos;t know the term $a[URI] and continue using the term $a[URL].
		From the looks of it, the Android-specific parts of the $a[API] use the correct term, $a[URI], but the parts of the $a[API] inherited from Java use the legacy term $a[URL], which is where the confusion comes in.
		I think Google made the right call in setting the $a[API] up this way.
		Developers familiar with Java still have their knowledge of Java method names to make use of, not to mention the wealth of information on Java on the Internet, but Android isn&apos;t introducing new $a[API] methods that use the legacy name.
	</p>
	<p>
		A bit later, Google makes the claim that if there&apos;s an authority component in a $a[URI], there must be a slash between the path and the authority.
		I know it&apos;s a bit of nitpicking, but strictly speaking, this is actually not true, and there isn&apos;t allowed to be anything between the authority and the path.
		Rather, the path must either be an empty string or begin with a slash.
		This makes a difference when parsing $a[URI]s.
		The difference is that the slash is actually <strong>*a part of*</strong> the path an not a delimiter between the path and the authority.
		Google also makes the claim that the query component has no required format, which I guess is partly true, but there are some limitations.
		Firstly, only certain characters are even allowed in query components.
		And secondly, the usual $a[URI] encoding using the percent character is valid, meaning that while percent signs are allowed, they&apos;re only allowed when followed by two hexadecimal digits.
		(As a side note, I&apos;ve done <strong>*way*</strong> too much reading of $a[URI]-related $a[RFC]s.)
	</p>
	<p>
		Hilariously, one of the quiz questions about $a[URI]s doesn&apos;t allow you to select the correct answer.
		It asks what the query component is in the $a[URI] <code>geo:0,0?q=Montreal,Canada</code>.
		The query component is the part of the $a[URI] after the first question mark and before the pound sign.
		Only one pound sign is allowed in a $a[URI], and if the pound sign comes before the first question mark, or if there is no question mark, there is no query component.
		With that in mind, the query component is obviously <code>q=Montreal,Canada</code>, but that option wasn&apos;t available.
		Instead, the options Google gave for what the query component might be were <code>geo:0</code>, <code>0,0?</code>, <code>Montreal,Canada</code>, <code>q=Montreal</code>, and <code>0?q=</code>.
	</p>
	<p>
		I found it surprising that Android uses $a[UTF]-16 for character encoding.
		That means that every character takes at least two bytes to store.
		That eliminates the compression of characters in the $a[ASCII] range to one byte, but also reduces the number of characters that can be stored in less than three bytes.
		Of course, if extra space is needed to specify a character, $a[UTF]-16 has to jump up to four-byte characters.
		You don&apos;t get to use three-byte characters like you do in $a[UTF]-8.
		With that in mind, using $a[UTF]-16 was an interesting choice, but it might be better for supporting languages that use upper ranges of characters.
		Or maybe Google did it for the emoticons.
		Google does some goofy things at times, so I wouldn&apos;t put that past them.
	</p>
	<p>
		I knew that newer versions of Android ask the user before allowing each application to use permissions.
		In that way, even if an application requests a certain permission that it doesn&apos;t need, you can install it and simply deny that permission.
		However, what I didn&apos;t know is that Android only asks the user about permissions Google thinks are sensitive.
		In other words, you can&apos;t simply deny whatever permissions you want to.
		You can only deny permissions that are on the list of ones Google thinks you should be concerned with.
		That&apos;s a bit of a let-down.
	</p>
	<p>
		One of the lessons made the claim that the &quot;save&quot; button is a relic from a bygone era, which I can kind of get behind as far as control + &quot;s&quot; is a better option, but that doesn&apos;t fit the context of what they were saying.
		They said that a good application should do what the user wants without them having to ask for it.
		In a great many cases, you do <strong>*not*</strong> want your application automatically saving your partly-edited files on you!
		You can leave your files in a broken state, not to mention that you might be trying some things out and end up wanting to discard your changes.
		There are some cases in which automatic saving makes sense, but these are contexts in which a &quot;save&quot; option was never introduced in the first place.
		The option to manually save your work (which comes with the equally-important option to <strong>*not*</strong> save your work) is in no way a legacy feature.
		It&apos;s still a vital functionality in many workflows, including my own.
	</p>
	<p>
		It seems that several methods in the Android $a[API] have the name <code>TextView.setText()</code>.
		As I mentioned previously, this sort of behaviour leads to errors.
		Google brought up another error I hadn&apos;t thought of: the wrong method might get called when you pass in the wrong arguments.
		In the case mentioned, they wanted to call the function that takes a string argument, but if not careful, would have instead called the function by that name that takes an integer argument.
		As Google put it, in the best case, the wrong text would be displayed, as the integer used as an input would provide valid output that was wrong for the situation.
		In the worst case, the integer wouldn&apos;t be valid input and would crash the application.
		These would both be runtime errors, and not caught by the compiler.
		On the other hand, if these methods each had a unique name, passing an integer into the one that requires a string as input would cause a compile-time error, and the code could be fixed right away, with no risk of accidentally letting that bug slip into the released version.
		Assuming Java disallowed multiple methods sharing a name and could therefore generate proper error messages, you&apos;d even get an error message telling you you&apos;d used the incorrect argument type, and could easily see the problem and fix it in your code.
		This shows the problem in the Java language&apos;s decision to allow multiple methods to share a name, but also shows a problem in the Android $a[API] used by taking advantage of that noxious Java feature.
		Hilariously, Google soon says that type safety is great to have, and type safety is exactly something you don&apos;t get when multiple methods can share a name.
		Method overloading makes typing issues problematic, as Java can&apos;t detect that you used the wrong type of argument, and instead thinks you intended to call an entirely different method with an entirely different function body.
		Method overloading <strong>*takes away*</strong> a good portion of your type safety, as you not only don&apos;t get assurance that your variable is of the right type, but also don&apos;t even get assurance that the right method is even being called.
	</p>
	<p>
		I find it incredibly bizarre that Android ends processes and restarts them when you change the screen orientation.
		I&apos;m sure there&apos;s some good reason for this behaviour, though the videos certainly didn&apos;t tell what it was.
		They tried to justify it as being because there are multiple possible screen configurations, so when those change, you&apos;ve got to kill the process and restart, but that doesn&apos;t actually explain anything.
		I mean, look at desktop applications.
		You can change your screen resolution or orientation on your desktop machine without killing any of your visible processes, even though the case of changing these settings on a desktop are <strong>*far*</strong> less common on a desktop machine.
		Somehow, desktop machines are doing better than mobiles for a use case that mobiles deal with daily while desktops deal with once in a blue moon.
		And to top it off, the main issue with screen orientation on a mobile seems to be that processes (the ones referred to as &quot;activities&quot; on Android, I mean) are full screen.
		That means that changing the orientation of the screen changes the window shape, or rather, the shape of the equivalent to a window.
		That means that the problem is similar to when I change the size of my browser window.
		Yet somehow, Firefox handles this change in dimensions just fine without needing to restart.
	</p>
	<p>
		Room seems like a complicated way to access a database.
		Supposedly, it&apos;s supposed to reduce the amount of boilerplate code you need to write, if I understand correctly.
		However, you seem to need to implement all the tables and rows as objects and bind those to the database, which is confusing to figure out and means writing code you otherwise wouldn&apos;t need.
		I guess you get out of writing boilerplate code, but in exchange, you write other code, so you&apos;re still needing to write a bunch of code, and the code you write isn&apos;t as easy to follow.
		I imagine once you get familiar with Room more, Room-based code will be less confusing, but you&apos;re still learning to use this new system just to change what kind of code you&apos;re writing, not get out of writing as much code.
		I don&apos;t see what you get out of that.
	</p>
	<p>
		The videos justified putting a simple counter in a background thread on the grounds that you might also want to make a network connection to send data on your drinking habits to a third party that keeps track of all your health-related data.
		Wow.
		Creepy.
		My mother once tried to give me a wristband that keeps track of heart rate and steps taken and sends it to a third party for tracking through one&apos;s mobile.
		It was completely incompatible with my device and there was no interface to see this data without uploading to the creepy tracking server, so the thing was completely useless to me and I&apos;m not sure why she bought it for me.
		Ignoring that though, even if the thing <strong>*was*</strong> compatible with my device, there&apos;s no way I would have used the thing.
		It&apos;s none of anyone&apos;s business but my own, and there was absolutely no reason whatsoever to give this information to some company that&apos;s tracking the health data of thousands of people.
		Who even knows what they&apos;re using all this data for?
		Most companies have some ulterior motive for wanting to store personal data from users.
		And with the application it communicates through being proprietary, you can&apos;t even check the source code to see what else the application is doing on your device.
		It&apos;s ridiculously shady, but what&apos;s truly ridiculous is that most users are so oblivious to how shady it is.
	</p>
	<p>
		Then again though, the water-reminder application the videos walked through the building of was completely ridiculous anyway.
		There is absolutely no scientific evidence that it&apos;s a good idea to drink water every fifteen minutes like this application reminds you to do, and the medical consensus, contrary to popular myth, is that your body will notify you when it needs water through feelings of thirst, and that if you drink when thirsty, you&apos;ll be just fine.
		We evolved to have thirst for a reason.
		As this application is, as the videos put it, just a toy application used to teach some core concepts, it&apos;s fine for its premise to be nonsensical, but while we&apos;re on the topic of how it&apos;s not a good idea to send your health information to third parties, I might as well point out that the entire application idea is just as flawed as the component with the outright dangerous mindset.
	</p>
	<p>
		The videos showed us how to compare versions using the goofy names for Android versions that I recommend against using.
		Apparently, the versions are assigned integers that are given named constants for ease.
		This only provides ease though if you buy into the obnoxious version names instead of using proper version numbers.
		I have to wonder if there&apos;s an easy way to compare the version of Android on a user&apos;s device with other versions using version numbers too.
		If not, you&apos;ve got to hard-code the version-identification numbers into your application after experimenting to find out what those integers are, which is, to be honest, an ugly hack.
		It&apos;s not preferable.
		(The other option, of course, is to buy into the obnoxious version names, which is an unacceptable solution.
		Even the hacky hard-coded version numbers would be preferable to that, though should definitely be given comments in the code to explain what the integers mean.
		It would probably even be a good idea to set some constants in your application to refer to the integers for further clarity.
		And to be clear, using version names instead of version numbers is quite unclear, so again, using the version names instead is a very bad idea.)
	</p>
	<p>
		It seems that using a <code>FirebaseJobDispatcher</code> requires using a <code>GooglePlayDriver</code>, and the latter of the two is a part of Google Play Services, which itself is a part of Google Apps.
		For me, this means I should avoid using these classes, as they require proprietary code to function.
		If I were to use these classes in my applications, I wouldn&apos;t even be able to run them on my own device, which is free of proprietary components.
		For other people that don&apos;t mind non-free dependencies, such as people writing proprietary applications themselves, it&apos;s still worth noting that these classes are going to make it harder to support as many devices.
		For example, Fire OS is a fork of Android used by Amazon devices, such as the Kindle.
		It doesn&apos;t have Google Apps installed, but does have much of the same $a[API] as Android.
		Using these classes would make your application not compatible with Fire OS devices.
	</p>
	<p>
		Constraint layouts seem pretty nice.
		You can do a lot with them, while still having your layout remain flexible enough to handle various screen sizes.
	</p>
	<p>
		Google says that it&apos;s easy to make your application accessible and convertible to other languages as long as you&apos;re mindful about it.
		Honestly, this applies so much to webpages too.
		However, so many Web developers ignore these sorts of things.
		On a website, you might not have the time to translate all the text to several other languages, as there&apos;s so much more text on a website than there is in an application, not to mention that it&apos;s in paragraph form, so you can&apos;t simply translate short phrases, and have to worry about grammar.
		There&apos;s absolutely no excuse for failing to make webpages accessible though, and yet so many Web developers fail so hard in that regard.
	</p>
	<p>
		Google says you should automatically transfer settings across devices, so the same settings are available on all of a user&apos;s devices.
		If you do that to me though, I&apos;ll get creeped out that one of my devices is using settings I never gave that particular device, realise you must be tracking me across devices, and uninstall your application from all my devices.
		For some users, tracking them across devices might be a welcome experience, but it certainly isn&apos;t a welcome experience for all of us.
	</p>
	<p>
		When Google brought up different pixel densities in the context of images used in an application, I thought they were going to recommend $a[SVG] images, as they&apos;d brought those up before.
		Instead, they recommended including several sizes of image in your application and coding the application to choose the right one for the right screen resolution.
		I have to wonder what the advantage of that is; it seems like extra work for no gain.
		As they mentioned before, Android does support $a[SVG] files, and if you use one of those instead of raster graphics, only one image file is needed.
		Vector graphics scale cleanly, so there&apos;s no issue of scaled images being distorted.
		I suppose having multiple sizes of image would be better in a few edge cases, such as photo-realistic images, but in an application, you usually don&apos;t use photo-realistic images, and instead use graphics with few colours comparatively and basic shapes (or rather, shapes that could be composed of basic shapes), which vector graphics handle quite well.
	</p>
</section>
<section id="Unit5">
	<h2>Unit 5</h2>
	<p>
		This week was odd.
		The so-called &quot;reading assignment&quot; didn&apos;t involve reading at all, but instead, was actually a series of small exercises.
		None of them were anything really new to me though.
		I&apos;ve worked with Java in <a href="https://y.st./en/coursework/CS1102/" title="Programming 1">CS 1102</a>, <a href="https://y.st./en/coursework/CS1103/" title="Programming 2">CS 1103</a>, <a href="https://y.st./en/coursework/CS3303/" title="Data Structures">CS 1103</a>, and perhaps other courses.
		It&apos;s difficult to check exactly what courses I&apos;ve used Java in at the moment with my notes and past coursework in their current censored state.
		In any case, I&apos;m no stranger to Java.
		It&apos;s by far one of the languages I use least, but I can write basic programs in it when I need to.
	</p>
	<p>
		We started out with a literal &quot;hello world&quot; script.
		We then removed some of its output, and next, had it output a random number.
		Different languages seem to handle random number generation differently.
		Java handles it by giving you a random float between zero and one.
		As the instructions showed, in such a language, it&apos;s easy enough to convert that into an integer within a desired range though, which is often times what you want.
		Next, we added an <code>import</code> statement and made use of the <code>java.util.Scanner</code> class to accept use input from the command line.
		Finally, we implemented conditional statements.
		All of these things are very basic, but if you&apos;re working in Java, they&apos;re things you should know how to do.
		I was surprised to see that we didn&apos;t work with any sort of loops though.
		Loops are another basic functionality that every programmer should know how to use.
		And if this course is teaching something as basic <code>System.out.println()</code> calls, I assume this is meant to be an entry-level programming course.
	</p>
	<p>
		The discussion assignment was kind of odd too.
		It asked what languages were popular, what Java can be used for, and whether Java skills could help someone in their career.
		I mean, I know I said this seems like an entry-level programming course, but it&apos;s an entry-level programming course with a specific focus on developing on mobile platforms.
		What do any of those things have to do with mobile platforms?
		On Android, it doesn&apos;t matter what languages are popular.
		You use Java.
		You <strong>*have*</strong> to use Java.
		It&apos;s my understanding that you can create a sort of wrapper application written in Java that runs non-Java code on Android, but the only real reason to do that would be if you have an existing application written in a non-Java language and want to port it to android.
		Having an existing project with a chosen language, it doesn&apos;t matter what languages are popular.
		As for Windows and iOS, I&apos;m not sure if mobile versions of Windows use a specific language (my guess is that they don&apos;t, but it wouldn&apos;t surprise me if they do), and I think iOS uses Objective-C or something.
		Again, I&apos;m not sure how language popularity would be of much relevance even when developing applications for Windows mobiles though, even if all languages are available to it.
		What Java can be used for outside the context of mobile development is also irrelevant, by definition, to mobile development, so that&apos;s an odd thing to ask here as well.
		And whether Java can help in a career, again, is related to Java more than mobile development.
		This whole week was just odd, and didn&apos;t seem to fit with the course.
	</p>
	<p>
		With so little to write about this week, I suppose this week would have been a good time to finish the instructional videos that are due next week.
		Too late though.
		I finished those last week.
	</p>
</section>
<section id="Unit6">
	<h2>Unit 6</h2>
	<p>
		The reading assignment for the week was chapters two through four of <a href="https://index-of.co.uk/Android/Beginning%20Android%202%20-%20Murphy%20-%20Apress%20(2010).pdf">Beginning Android 2 - Murphy - Apress (2010).pdf</a>.
	</p>
	<p>
		The material for this week talked about getting Eclipse set up with the $a[ADT] plugin.
		We&apos;re not using Eclipse this term, but I sort of wish we were.
		I&apos;ve tried in the past to get Eclipse and $a[ADT] set up properly and I failed.
		If I develop Android applications, this is likely the environment I would do it in.
		Android Studio has licensing issues, as far as I know, so I wouldn&apos;t want it installed on my system.
		I&apos;d instead need to go old school, and use this setup that Google no longer recommends.
		If we were using this setup, perhaps we would have covered enough to let me know what I was doing wrong so I could get the development environment set up properly.
		Or if not, perhaps I could have asked for help in the course forum.
		But because we&apos;re not using this setup, asking about this setup would be off-topic.
	</p>
	<p>
		The part about how a Java project can contain third-party $a[JAR]s was news to me.
		I though that to compile your project, you&apos;d need the source code of all parts of your project.
		I guess that isn&apos;t the case.
		Precompiled code can be used within your project.
		Of course, I can&apos;t recommend using compiled code that you don&apos;t have the corresponding source code for, so this functionality doesn&apos;t exactly seem useful in practice, but it&apos;s interesting none the less.
	</p>
	<p>
		The videos we watched talked about putting certain things such as permission requests in the Android manifest, but didn&apos;t really discuss what that was.
		According to this week&apos;s reading assignment, it&apos;s a file for telling the Android system about the permissions the application needs and components the application has.
		It provides a sort of overview, and allows Android to know what it needs to deal with, sort of indexing the application in the process.
		Other systems can read the manifest too for various purposes.
		For example, application repositories such as F-Droid and Google Play can use the information found there to avoid presenting the application to incompatible devices.
	</p>
	<p>
		Another thing the videos didn&apos;t properly explain was the <code>R</code> class.
		Apparently, it&apos;s project-specific.
		Every Android application has a version of this class, and it&apos;s not a system class built into the $a[API] as it appeared to be when the videos demonstrated using it to manage resource files.
		Speaking of the resources that the <code>R</code> class manages, the <code>res/drawable</code> directory has an unintuitive name.
		It stores images.
		Why is it not <code>res/image</code> to make it easy to remember?
	</p>
	<p>
		Targets seem to lack the proper functionality to allow you to specify a newer device that doesn&apos;t have Google Maps installed.
		If you want to test without Google Maps, which I would always recommend, you have to target Android 1.1 or 1.5.
		Android 1.6 and 2.0 can only be targeted <strong>*with*</strong> Google Maps, according to the textbook.
		And with Google Maps not having available source code, you can&apos;t trust it, and expecting your users to trust it is very irresponsible.
		That said, the textbook appears to be old, saying that 2.0 is the latest targetable version.
		Perhaps the situation has been corrected by now.
	</p>
	<p>
		The textbook highlighted the purpose of &quot;hello world&quot; applications.
		I think it put very well what they do and why I&apos;ve always found them so pointless.
		They prove to the user that they can build something that runs.
		I&apos;ve always skipped over &quot;hello world&quot; projects when learning a new language.
		They&apos;re pointless, and a waste of my time.
		I know I can build something that runs.
		The question is whether I can build something <strong>*useful*</strong>!
		And a &quot;hello world&quot; script isn&apos;t useful.
		I think I had to build a &quot;hello world&quot; script for an assignment I had at this school, but two things set this script apart from other &quot;hello world&quot; activities foe me.
		First, I already knew the language pretty well, so this script was supposed to prove absolutely nothing to me.
		And second, it was a graded requirement, and submitting my coursework is actually useful, even if the behaviour of the script isn&apos;t at all.
		The book did seem to think the problem was one of &quot;hello world&quot; scripts being boring though, which for me, isn&apos;t the issue at all.
		It it&apos;s not useful, why program it?
		I&apos;d rather learn while building something I actually have a use for.
		In fact, when I&apos;m learning a new language outside the context of school, I usually have a specific project in mind, and I learn by working my way through how to build it.
	</p>
	<p>
		The textbook showed us that it&apos;s possible to create application layouts in pure Java code.
		That surprised me!
		The videos made it out like this isn&apos;t possible, and using $a[XML] layouts is absolutely mandatory.
		I mean, I&apos;m all for good practices and the $a[XML] layouts seem like a step in the right direction, but I feel like the videos are misleading people.
	</p>
	<p>
		A couple of the quiz questions this week were a little odd.
		Most notably, there was this one:
	</p>
	<blockquote>
		<p>
			If a method does not return any value, what type would it take?
		</p>
	</blockquote>
	<p>
		Not returning a value refers to return values, while <strong>*taking*</strong> types refers to input, meaning parameters.
		A void function can take whatever parameters it specifies!
		I&apos;m guessing it was looking for the key word used to denote that there&apos;s no return value though, so I selected <code>void</code>.
		The other odd one asked:
	</p>
	<blockquote>
		<p>
			What is a basic unit of a Java program or an object?
		</p>
	</blockquote>
	<p>
		Two of the options made no sense, so we could rule those out, but there were still the options of a class and a method.
		I guessed it was referring to classes, so that&apos;s what I selected, but a function is also a unit of code, and more basic than a class.
		It just isn&apos;t stand-alone, and requires a class to be defined in, not to mention that there are things that can&apos;t be included in a method, such as property declarations.
	</p>
</section>
<section id="Unit7">
	<h2>Unit 7</h2>
	<p>
		I&apos;d like to thank you.
		In my other course, my professor has been telling me to keep my word count low.
		I don&apos;t think they like reading paragraphs upon paragraphs of my text.
		I learn not by reading though, but by writing.
		When I&apos;m not allowed to write much, I don&apos;t learn much.
		I&apos;ve been able to learn much more in this course because you&apos;ve allowed me to write much more about what I&apos;m reading, helping me retain the knowledge I&apos;m gaining.
		I guess this entry&apos;s a lot shorter than my others, seeing as this week was mostly just review, but my longer entries from past weeks really helped me remember and understand the material.
	</p>
	<p>
		Last week, we were to submit a screenshot of the course list from the video lessons we were supposed to have watched.
		I couldn&apos;t fit it all on one screen, so I took three screenshots and stitched them together in the $a[GIMP].
		Of the students I graded this week, one submitted two screenshots and another four, again, because we can&apos;t get a good shot on one screen.
		One student panicked about how much the site had changed since the screenshot shown in the example though, and uploaded no less than <strong>*fifty-one*</strong> screenshots, just to make sure the graders understood that the videos had in fact been watched.
		Wow.
	</p>
	<p>
		This week&apos;s reading assignment was chapters nine, ten, and twelve of <a href="https://my.uopeople.edu/mod/resource/view.php?id=178261">The Busy Coder&apos;s Guide to Android Development</a>.
	</p>
	<p>
		I found it odd that the textbook was referring to Android&apos;s <code>TextView</code>s as &quot;labels&quot;.
		It didn&apos;t say they could be <strong>*used as*</strong> labels, but rather that they <strong>*are*</strong> labels.
		There&apos;s so much more that you can do with them than just label stuff though!
		And just a bit later, a demo was provided that did just that: use a <code>TextView</code> to display text on the screen in a way that didn&apos;t label anything.
		Furthermore, it seems that <code>Button</code> is a subclass of <code>TextView</code>.
		That means that every <code>Button</code> is a <code>TextView</code>, similar to how every square is a rectangle; squares are a subclass of rectangles.
		If we&apos;re referring to <code>TextView</code>s as labels, that means that <code>Buttons</code> are labels!
		That can&apos;t be right.
		Furthermore, <code>EditText</code> is a subclass of <code>TextView</code>, meaning that these text-entry fields would also be labels.
		Again, this points to <code>EditText</code> being labels.
		<code>CheckBox</code>es and <code>RadioButton</code>s are likewise <code>TextView</code>s.
		Clearly, while a <code>TextView</code> can be used as a label, <code>TextView</code>s themselves are not labels in and of themselves.
	</p>
	<p>
		The section on containers went more in-depth than the video lessons did.
		In particular, the part about how to size elements within a container was useful.
		Having the weight of a widget be zero by default when filling the remaining space was an odd choice by Google though.
		It seems that the weights of the widgets are added together to form a denominator, then the weight of an individual weight becomes the numerator in the fraction representing how much of the remaining space the widget will take up.
		I could see right away that that means that if any widget has a non-zero weight, all the widgets with the default weight will simply not get any screen space.
		I think if all the widgets have zero weight though, the space is just divided amongst them evenly, but I&apos;m not sure on that.
		Padding and margins are work as expected, if you&apos;ve at all worked with $a[CSS] before.
		That seems predictable, seeing as Google was a Web-based company <strong>*long*</strong> before developing Android.
		They would be familiar with $a[CSS] terms and know how to properly use them.
	</p>
	<p>
		The textbook says that if you like $a[XHTML]/$a[HTML] <code>&lt;table/&gt;</code>s, you&apos;ll like Android&apos;s <code>TableLayout</code> because it allows you to position widgets in a grid-like way.
		However, it&apos;s worth noting that this is an <strong>*improper*</strong> use of <code>&lt;table/&gt;</code> tags, and makes it difficult for assistive technologies such as screen readers to convey the meaning of a page to their user!
		<code>&lt;table/&gt;</code> tags are meant <strong>*only*</strong> for tabular data, and never just to assist in building the layout of the page.
		With that in mind, if you use the <code>&lt;table/&gt;</code> tag <strong>*correctly*</strong>, and you like the <code>&lt;table/&gt;</code> tag, it doesn&apos;t say anything about whether you&apos;d like a grid-based layout for non-tabular data, such as Android&apos;s <code>TableLayout</code> provides.
	</p>
</section>
<section id="Unit8">
	<h2>Unit 8</h2>
	<p>
		This week&apos;s reading assignment was chapters eight through fourteen of <a href="https://my.uopeople.edu/mod/resource/view.php?id=178261">The Busy Coder&apos;s Guide to Android Development</a>.
		We already read chapters nine, ten, and twelve last week though, so when it comes to new material to cover in our learning journals, we only have chapters eight, eleven, thirteen, and fourteen this week.
	</p>
	<p>
		On the topic of the review chapters from last week though, the book informs us of how to set various text properties for a <code>TextView</code>, incorrectly referring to these widgets as &quot;labels&quot;.
		Those can be useful for emphasis and for style.
		I didn&apos;t see a way to change text styles partway through an element&apos;s text though, which makes use for emphasis much harder.
		You need three <code>TextView</code>, one for before, one for during, and one for after the emphasis.
		Trying to get text to still flow normally and fill the container correctly regardless of screen size though seems like a daunting task.
		I have to wonder if there&apos;s an easier way to emphasise text in Android.
	</p>
	<p>
		I thought that Chapter 8 was one that we&apos;d covered already because it seemed so familiar.
		Reading my past learning journal entries again though, it looks like it was a different textbook we read that covered this same material, so we didn&apos;t technically read this chapter.
		Still, it was complete review for us.
		The more I read of the chapter too, the more key phrases I recognised.
		It was like they were word-for-word identical or something.
		It was a bit distracting, honestly.
		I kept going back to make sure this really wasn&apos;t the chapter we&apos;d already read, checking both my learning journal and the school lesson plans.
	</p>
	<p>
		Input type hints seem like a good idea mostly, though I wonder if the format of the date entered by a user is checked for validity before Android allows the user to submit the value.
		If so, I really hope the date format can be set by the developer in some way.
		Android doesn&apos;t use $a[ISO] 8601 like it should when using other date-related widgets such as <code>DatePicker</code>, so if it&apos;s attempting to validate against some other date format, dates in the international standard format would be rejected, which isn&apos;t right.
	</p>
	<p>
		The more-advanced usage of <code>ListView</code>s covered by the textbook this week explains a lot.
		When we first read about <code>ListView</code>s, which I think was last week, they seemed almost right for what might be used in applications such as email clients, file manager, contact managers, and things such as that, but these applications - at least the ones I&apos;ve used - use more than just text.
		Normally, the extra garbage they pack around the text would just be bloat, but on a touchscreen, they pad out space that has to be used for making the list items larger anyway.
		The list items need to be large so you don&apos;t fat-finger the list items as often.
		Useful or not though, there&apos;s typically icons and the like around these things, which didn&apos;t fit with what we&apos;d read about <code>ListView</code>s up to that point.
		It seems that these things are likely handled by <code>ListView</code>s after all though.
		Developers aren&apos;t stuck reinventing these mechanics that are common enough that they really should be handled by something built-in.
	</p>
	<p>
		Setting up a tabbed activity seems a lot easier than I would have expected though.
		I don&apos;t see tabs in Android applications often, and they aren&apos;t something I&apos;d&apos;ve thought there would be $a[API] options specifically for.
		I would have thought that tabs would be one of those things that, when even needed at all, the programmer would have to implement using <code>Button</code>s or the like and code the swaps out the layout.
		The more generic form, <code>ViewFlipper</code>, looks like it probably provides the functionality I&apos;ve seen in several applications though.
		Tabs don&apos;t seem that common on the mobile applications I&apos;ve seen, but flipping between different content without tabs certainly does.
	</p>
	<p>
		The final exam was pretty easy.
		Though I learned a lot in the course, almost nothing I didn&apos;t already know before taking this course was actually on the exam.
		I&apos;m kind of disappointed that we never got around to actually building any applications in this course.
		We read about building applications, and we watched videos about building applications, but we never actually constructed any of our own.
		I guess that might have been a good thing for me.
		I&apos;ve tried to set up an Android development environment on multiple occasions, and I never can get it working.
		I might have hit that same problem again in this course, had we actually needed to do that.
		I was hoping though that if I had problems again, I could ask for help and someone might be able to show me what I was doing wrong.
		Maybe I wouldn&apos;t be able to get help though, and maybe I would have instead had to fail whatever assignments involved building applications.
		If we&apos;d needed to set up an iOS or Windows development environment on the other hand, I&apos;m almost certain I wouldn&apos;t be able to find software for that that I could actually install on my Debian system.
		I would have almost certainly failed, had we done any non-Android development, even if I&apos;d managed to get the Android development environment working perfectly.
		Maybe between terms though, I&apos;ll try again to set up Eclipse and $a[ADT].
		Then again, I can&apos;t build much of use anyway until I have a device with a working battery.
		I still need to buy a new battery to replace my cracked one, and it&apos;ll take several weeks to arrive in the mail, most likely.
		I should remember to get the new battery between terms, then when it arrives, see if I can get the development environment set up correctly and put into practice some of what I&apos;ve learned this term.
	</p>
</section>
END
);
